"Zwei Seelen wohnen, ach! in meiner Brust“ – Ein Certified Tester in der agilen Transition

Der Vortrag ist ein persönlicher Erfahrungsbericht zur agilen Transition.

In 2014 wurde bei ista mit der Einführung des Scaled Agile Framework (SAFe) für die Softwareentwicklung begonnen. Mehr als zwanzig Teams entwickeln bei ista Software in der Regel Scrum-orientiert. Persönlich bin ich ein Mitglied im System Team, welches unter anderem die systemübergreifenden End-to-End-Tests als Aufgabe hat. Immer wieder war und bin ich mit Situationen konfrontiert, in denen ich hin - und hergerissen bin zwischen den Einschätzungen meiner traditionellen, ISTQB -fokussierten Herkunft und den Anforderungen und gelebten Prozessen, die sich in der noch immer andauernden agilen Transition ergeben.

Dabei ist anzumerken, dass der Konflikt nicht immer durch den agilen Prozess an sich entsteht, sondern sich in einigen Fällen durch die gelebte Praxis ergibt. Eine höhere agile Reife (stärkeres Leben agiler Werte und Prinzipien sowie eine bessere Implementierung des Scaled Agile Frameworks) würde einige dieser Konflikte sicherlich vermeiden.

Im Vortrag werde ich beispielsweise auf die folgenden Bereiche eingehen:

• Akzeptanzkriterien vs. Risiko

Immer wieder kommt es vor, dass Akzeptanzkriterien zwar nicht bis ins letzte Detail erfüllt sind, aber das damit verbundene Risiko als höchst gering eingeschätzt wird. Als klassischer Tester ist mir die Nichterfüllung einer festgelegten Anforderung ein Dorn im Auge, gleichzeitig muss ich aber auch eingestehen, dass das sehr geringe Risiko den Aufwand für das Glattziehen nicht unbedingt rechtfertigt.

• Abweichungen berichten vs. Abweichungen gelöst bekommen

Eine deutliche Veränderung in der agilen Transition wird im Abweichungsmanagement deutlich. Immer weniger Abweichungen werden nachvollziehbar dokumentiert und immer mehr Abweichungen werden in kurzer Abstimmung gelöst. Die richtige Balance zu finden – insbesondere in einem Kontext mit l ängeren Feedbackzyklen – ist eine andauernde Suche.

• Spezifikation vs. Feature-Beschreibung

Als traditioneller Tester sehne ich mich manchmal nach einer guten alten Spezifikation. Diesen Wunsch nehme ich auch von einigen Teams wahr. Gleichzeitig sollte eine Feature - Beschreibung so leichtgewichtig wie möglich erfolgen und Details sollten zwischen Teams direkt abgestimmt werden. Wie kann hier das richtige Gleichgewicht gefunden werden?

• Qualitätsverantwortung vs. E2E-Tests

Als traditioneller Tester bin ich es gewohnt, dass sich Tester für das Finden von Fehlern und das Sichern von Qualität verantwortlich fühlen. Letztendlich kann dieser Ansatz kaum erfolgreich sein, aber es ist sehr schwierig, sich auf die wesentliche Aufgabe der End -to-End- Tests zu konzentrieren, wenn man weitere Gebiete zur Qualitätsverbesserung in der Verantwortung von Teams sieht.

• Aufgabendefinition vs. Tu das, was sinnvoll ist

Im Fokus des System Teams liegen unter anderem die End -to-End-Tests. Gleichzeitig stellen wir aber auch Lücken in den Tests und Vorgehensweisen der einzelnen Teams fest. Dies führt dazu, dass wir teilweise die Aufgaben von Teams übernehmen. Klassisch spricht einiges dafür, dass jeder in seiner Verantwortlichkeit arbeiten sollte. Gleichzeitig rückt ein Handeln im Interesse des Gesamtprojekts immer stärker in den Fokus. Wir versuchen, beides zu erreichen.

• Zeige deinen Nutzen vs. Mach dich überflüssig

Zu Beginn der agilen Transition war die Sichtweise auf die End -to-End-Tests sehr klassisch geprägt. Im Laufe der Zeit stellt sich immer mehr heraus, dass im Interesse des Agile Release Trains eine stärkere Verantwortung der Teams für integrative Tests und auch End - to-End-Tests sinnvoll ist. Das hinterlässt ein wenig die Sorge (aber nährt gleichzeitig auch die Hoffnung), dass man irgendwann überflüssig sein könnte. Dieses Spannungsfeld ist durchaus eine Herausforderung.

Ich arbeite zwar in einem SAFe-Kontext, bin aber davon überzeugt, dass sich die Herausforderungen und Zerrissenheit auf viele Situationen in einem typischen agilen Team übertragen lassen.

zurück zum Programm